transition in custom element #4998
Conversation
There was a problem hiding this comment.
According to https://caniuse.com/#feat=mdn-api_node_getrootnode .getRootNode() is not supported on IE - and, since it's a method on an existing class, it's not something that can be polyfilled very well. I believe this change would break all transitions on IE.
|
@Conduitry so that's why nobody had thought of that "excellent" idea 🤦 😅 |
|
This problem breaks svelte transitions whenever svelte component is injected into shadow dom. I'm not using custom-element option and transitions are still broken. I think it's a pretty common case to inject svelte components into shadow-dom. This PR would help my team a lot. |
|
Is something blocking this PR to be merged after commit #5b5a934? |
|
As long as the PR is still open you can use the build script in the custom-elements template that I created. It fixes the transition using .getRootNode(). Custom element template: https://github.com/redradix/svelte-custom-element-template |
|
Thanks @MonkeyAndres! Your solution is fixing all the most common problems with custom elements, but it's pretty hacky. I would advise anyone who want to use it, to read carefully through the build script. Just to be aware of what kind of hacks are there. Using regex to replace |
|
Totally agree with you @Buk1m as I say in the README this is my solution to these limitations, if you find out a less "hacky" way of fixing these problems feel free to open an issue or PR in the repo. |
|
@Conduitry could you please have a look at this PR again? |
hontas
force-pushed
the
custom-element-transition
branch
from
a256c6e to
f36e84c
Compare
|
Does anyone need help landing this? Really looking at svelte with custom elements but I’m really looking to help with getting PRs around it to land. I’m happy to help! |
| } | ||
|
|
||
| function get_root_node(node) { | ||
| if (is_function(node.getRootNode)) return node.getRootNode(); |
There was a problem hiding this comment.
I found a weird behaviour doing so, let's suppose we have a transition on hover on an element, if the element on which we want to apply the transition is directly a child of a shadow-root element it will be okay, if otherwise it's a child of a regular DOM node (let's say a div) it will keep on appending style tags on each hover. Looking recursively for a parenElement to get to the root of the webComponent solves the issue.
There was a problem hiding this comment.
Interesting, thanks. Could you show me your code so I can have a look as well?
hontas
force-pushed
the
custom-element-transition
branch
8 times, most recently
from
dce169b to
2b57dce
Compare
hontas
force-pushed
the
custom-element-transition
branch
from
2b57dce to
894f8b7
Compare
|
@hontas Is there anything preventing this from getting merged? |
|
@vultix yes I’m still waiting for feedback / approval from the maintainers on this one. I asked for another review a while back but I’m not sure how to escalate this to get attention. |
|
Isn't this PR a subset of the functionality of #5870? |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Apologies, looks like this got lost in the mix. I'm going to close it since Svelte 5 has a very different mechanism — happily, this should all Just Work since it's based on Web Animations rather than CSS hackery. |
fixes #1825
The problem
The style-element containing the transition CSS is appended to the head-element which is unseeable from within the shadow dom.
The fix
This fixes that by adding the style element to the shadow DOM (for custom elements).